Backup files to a disk image

ABSTRACT

Performing a file backup includes receiving a file to backup from a source machine and performing a write operation to write the file to a mount point in a file system on a backup server. The backup also includes intercepting a block-level data block to be written which is generated by the write operation; and writing the block-level data block to a corresponding, respective block of a disk image file having a plurality of blocks.

BACKGROUND

The present disclosure relates to data backups, and more specifically,to file-level and block-level backups.

When backing up data, two different methods are typically used. Onemethod is file-level backups which performs the backup task by copyfiles and directories to a separate folder (or directory) structure. Thegranularity of this type of backup allows a small subset of folders orfiles to be designated for backup. Also this method allows flexiblebackup policies for different data types on the same volume. Forexample, the backup policies for documents, photographs, videos, etc.can all be different even though they reside on the same volume. Thismethod also has detriments such as being time consuming for largeamounts of data and copying a whole file during a backup operation eventhough only a small portion of the file may have changed.

Another backup method is at the block-level. A block-level backup isdefined at blocks which are generally a group of disk sectors. This typeof backup is at a lower level than files and folders and is performedbelow the file system level. Generally, block-level backups are used toaccomplish disk-to-disk copies or volume-to-volume copies. Block-levelbackups allow backing up or restoring an entire volume or disk as blockunits. Block-level backups utilize more sophisticated software thanfile-level backups and typically require kernel-level drivers such as asnapshot driver and a change tracking driver to perform their tasks.

BRIEF SUMMARY

According to one aspect of the present disclosure, a system includes aprocessor; a storage device coupled to the processor, and a memorycoupled to the processor, the memory configured to store program codeexecutable by the processor. In particular, the program code, whenexecuted by the processor, is configured to receive a file to backupfrom a source machine and to perform a write operation to write the fileto a mount point of a file system on the storage device. The programcode, when executed by the processor, is also configured to intercept ablock-level data block to be written which is generated by the writeoperation and to write the block-level data block to a corresponding,respective block of a disk image file having a plurality of blocks.

According to another aspect of the present disclosure, a method includesreceiving, by a computer, a file to backup from a source machine andperforming, by the computer, a write operation to write the file to amount point of a file system on the computer. The method also includesintercepting a block-level data block to be written which is generatedby the write operation; and writing the block-level data block to acorresponding, respective block of a disk image file having a pluralityof blocks.

According to another aspect of the present disclosure, a computerprogram product includes a computer readable storage medium havingcomputer readable program code embodied therewith. The computer readableprogram code includes computer readable program code configured toreceive a file to backup from a source machine; to perform a writeoperation to write the file to a mount point of a file system on abackup server; intercept a block-level data block to be written which isgenerated by the write operation; and to write the block-level datablock to a corresponding, respective block of a disk image file having aplurality of blocks.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present disclosure are illustrated by way of example andare not limited by the accompanying figures with like referencesindicating like elements.

FIG. 1 illustrates an example computing environment for performing databackups in accordance with the principles of the present disclosure.

FIG. 2A is a flowchart of an example process for backing up files to adisk image in accordance with the principles of the present disclosure.

FIG. 2B illustrates a logical diagram of how a disk image is constructedin accordance with the principles of the present disclosure.

FIG. 3A is a flowchart of an example process for performing a fullbackup to a disk image in accordance with the principles of the presentdisclosure.

FIG. 3B illustrates a logical diagram of how further details of how adisk image is constructed in accordance with the principles of thepresent disclosure.

FIG. 3C is a flowchart of an example process for performing anincremental backup to a disk image in accordance with the principles ofthe present disclosure.

FIG. 3D illustrates a logical diagram of how further details of how anincremental disk image is constructed in accordance with the principlesof the present disclosure.

FIG. 4 illustrates a block diagram of a data processing system inaccordance with the principles of the present disclosure.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, aspects of the presentdisclosure may be illustrated and described herein in any of a number ofpatentable classes or context including any new and useful process,machine, manufacture, or composition of matter, or any new and usefulimprovement thereof. Accordingly, aspects of the present disclosure maybe implemented entirely hardware, entirely software (including firmware,resident software, micro-code, etc.) or combining software and hardwareimplementation that may all generally be referred to herein as a“circuit,” “module,” “component,” or “system.” Furthermore, aspects ofthe present disclosure may take the form of a computer program productembodied in one or more computer readable media having computer readableprogram code embodied thereon.

Any combination of one or more computer readable media may be utilized.The computer readable media may be a computer readable signal medium ora computer readable storage medium. A computer readable storage mediummay be, for example, but not limited to, an electronic, magnetic,optical, electromagnetic, or semiconductor system, apparatus, or device,or any suitable combination of the foregoing. More specific examples (anon-exhaustive list) of the computer readable storage medium wouldinclude the following: a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an appropriateoptical fiber with a repeater, a portable compact disc read-only memory(CORaM), an optical storage device, a magnetic storage device, or anysuitable combination of the foregoing. In the context of this document,a computer readable storage medium may be any tangible medium that cancontain, or store a program for use by or in connection with aninstruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device. Program codeembodied on a computer readable signal medium may be transmitted usingany appropriate medium, including but not limited to wireless, wireline,optical fiber cable, RF, etc., or any suitable combination of theforegoing.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including MAINFRAME Assembler, an object orientedprogramming language such as Java, Scala, Smalltalk, Eiffel, JADE,Emerald, C++, CII, VB.NET, Python or the like, conventional proceduralprogramming languages, such as the “c” programming language, VisualBasic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, dynamic programminglanguages such as Python, Ruby and Groovy, or other programminglanguages. The program code may execute entirely on the user's computer,partly on the user's computer, as a stand-alone software package, partlyon the user's computer and partly on a remote computer or entirely onthe remote computer or server. In the latter scenario, the remotecomputer may be connected to the user's computer through any type ofnetwork, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider) or ina cloud computing environment or offered as a service such as a Softwareas a Service (SaaS).

Aspects of the present disclosure are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatuses(systems) and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable instruction executionapparatus, create a mechanism for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that when executed can direct a computer, otherprogrammable data processing apparatus, or other devices to function ina particular manner, such that the instructions when stored in thecomputer readable medium produce an article of manufacture includinginstructions which when executed, cause a computer to implement thefunction/act specified in the flowchart and/or block diagram block orblocks. The computer program instructions may also be loaded onto acomputer, other programmable instruction execution apparatus, or otherdevices to cause a series of operational steps to be performed on thecomputer, other programmable apparatuses or other devices to produce acomputer implemented process such that the instructions which execute onthe computer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

As used herein, a “block” is a uniformly sized unit of storage for afile system (e.g., a block can be 4 KB in size). Thus, a file systemthat is 400 KB in size would be comprised of 100 blocks. The file systemincludes methods and data structures that an operating system uses tokeep track of files on a disk. It allows the user to assign symbolicnames to files and directories while maintaining a record of thespecific blocks that contain the data within those files anddirectories. Typically, the actual data stored on the disk will beorganized according to a file system which is implemented within anoperating system. User applications executing within that operatingsystem access data on the disk according to the file system'sorganization.

When a read or write request for data is received, the operating systemdetermines the blocks of the file system that are needed to satisfy therequest and then requests those blocks from the disk. At a disk devicedriver level, or possibly, at a disk hardware interface level, a blocknumber is translated into a physical location and data stored at thatphysical location is retrieved from, or written to, the disk.

A “disk image” is a single file containing the complete contents andstructure representing a data storage medium or device, such as a harddrive. A disk image is usually created by creating a completesector-by-sector copy of the source medium and thereby perfectlyreplicating the structure and contents of a storage device. Also, asused herein, the terms “folder” and “directory” are intended to besynonymous as they both refer to a way to organize groups of files in ahierarchical tree-like structure. A “volume” is a single accessiblestorage area with a single file system and is typically resident on asingle partition of a hard disk. A volume exists at the logicaloperating system level and partitions exist at the physicalmedia-specific level. Thus, an operating system can recognize apartition without necessarily recognizing any volume associated with it(e.g., when the operating system cannot interpret the file system typestored on the partition). A hard disk may, for example, have twopartitions “hda1” and “hda2” and on each partition resides a respectivefile system (e.g., files, directories, and organizational meta data).The operating system can assign a label to each partition's file systemsuch as “C:” and “D:” to create two volumes known as “C:” and “D:” inthe operating system.

FIG. 1 illustrates an example computing environment for performing databackups in accordance with the principles of the present disclosure. Inthe example environment there is a source machine 102 where the sourcefiles to be backed up are located. For example, the source files andfolders 112 may be stored in a disk drive or other storage device. Oneof the applications that can execute on the source machine 102 is abackup client 106. Using the backup client 106, a user can defineflexible backup policies for the files and folders 112 that involve fullor incremental backups of some or all of these files and folders 112. Inparticular, the user can use the back-up client 106 to define the backuppolicies at the file level (as opposed to the block level).

The environment of FIG. 1 also includes a backup server 104 on which isexecuting a backup application 108. The backup application 108 and thebackup client can communicate with one another over a network connection110. The backup client 106 determines the files and folders that need tobe backed up according to the user defined backup policies. This isperformed at the file level and a stream of data representing the filesis sent to the backup application 108. Once the backup application 108receives the data then it can launch routines to store the received datato the destination 114. As described more fully below, the writing ofthe data to the destination 114 can be performed at the block-level. Asa result, copies of the files and folders 112 of the source machine 102are created and stored at a destination storage device 114. As describedmore fully below, the copies that are created are done so at the blocklevel such that the copies on the storage device 114 resemble diskimages.

FIG. 2A is a flowchart of an example process for backing up files to adisk image in accordance with the principles of the present invention.Before the backup application 108 initiates, or causes the client 106 toinitiate, any backup jobs, the backup application 108 and the backupclient 106 exchange information about the storage devices where thefiles and folders 112 are located attached to the source machine 102. Inthe description below, operation of various backup processes andfunctions are described with respect to a single disk drive and itsassociated single disk image. One of ordinary skill will recognize thatthe described processes and functions can be repeated for additionaldisk drives without departing from the scope of the present disclosure.

Thus, in step 202, the backup application 108 receives from the backupclient 106 a description of the disk and volume layout of the disk drivewith the files and folders 112. The disk information includes the numberof logical blocks on the disk. The volume layout information wouldinclude which blocks are associated with each volume. For example on adisk having n blocks, a “C:” volume may utilize blocks 1 through x andthe “D:” volume utilize blocks x+1 through n. In general, the backupapplication 108 obtains information from the backup client 106 about:the number of different disks, each disk's size (in blocks), the numberof different volumes, each volume's size, and the file system type ofeach volume.

Once the backup application 108 receives this information, a disk imagecan be created, in step 204, for the disk drive with the files andfolders 112. While there is no data besides its metadata including thedisk size and the parent disk image if it exists at the present time inthe disk image, the backup application 108 can define the data structureand label that will become the disk image.

FIG. 2B illustrates a logical diagram of how a disk image is constructedin accordance with the principles of the present disclosure. In theexample of FIG. 2B, there are three volumes of one disk drive shown.Because there are three volumes on the disk, the disk image can beconsidered to have three different sections. Each of the three sectionsrepresenting one of the volumes. In step 206, the backup application 108virtualizes each volume device on the disk image and creates a filesystem for each of the volumes.

The backup application 108, within the file system of the backup server104, creates a respective folder for each of the three differentvolumes. For example, the folders could be named:

-   -   /backup/source/vol1    -   /backup/source/vol2    -   /backup/source/vol3        and each of the folders can be treated as a mount point within        the file system of the server 104 and its operating system.

For each of the three volumes, the backup application 108 can use therespective volume size and file system type to create a correspondingfile system. Each of the three file systems can then be mounted to oneof the appropriate mount points by the operating system of the backupserver 104. Thus, the three volumes that make up the disk image arevirtualized within the file system of the server 104. In other words, ifan application on the server 104 were to write a file to one of themount points, the backup application 108 could recognize that data asbeing written to one of the three volumes that are part of the disk thatis being backed up to a disk image. In FIG. 2B there are three mountpoints 220, 222, 224 that correspond to the three volumes on an exampledisk drive of the source machine 102. Each of the mount point 220, 222,224 correspond to an emulated volume (or section) 226, 228, 230 of thedisk image 232.

Thus, when file contents are received from the source machine 102 awrite operation to the mount-point folder acts as a normal file systemwrite to a physical disk drive. The operating system will convert thefile system write to a block-level write request to one of the filesystems created and controlled by the backup application 108. Thus, thebackup application 108 can intercept the block-level data in the filesystem write request and process the data before writing it to the diskimage 232 as one or more blocks 234.

Returning back to the flowchart of FIG. 2A, once the volumes and filesystems are created, a backup job can be initiated which, in step 208,causes the source machine 102 to discover folders and files that are tobe backed up in accordance with the predefined policies and rules. Instep 210, the file stream is received by the backup application 108where the backup application 108 processes the file data and writes oneor more blocks to the disk image 232. The actual disk image file is asingle file written to a hard drive by the backup server's operatingsystem, thus the disk image 232 of FIG. 2B is conceptual in nature inthat on the hard drive of the server 104, the first block of the diskimage file is not likely located at a logical block address of “1” forthat hard drive.

Backups can be classified according to whether it is a full backup or anincremental backup. A full backup assumes that no previous files havebeen backed up and the backup process will make a copy of all the filesand folders received from the source machine. An incremental backup, onthe other hand, backs up only files and folders that have changed sincethe last full or incremental backup. Therefore a restore from anincremental backup will utilize the most recent full backup relative tothe used incremental backup and all the incremental backups until thetime of the used incremental backup.

FIG. 3A is a flowchart of an example process for performing a fullbackup to a disk image in accordance with the principles of the presentdisclosure. The full backup process of FIG. 3A is presented with respectto one file or folder from the source machine; the same process would berepeated for all the source files and folders that are to be copied.

A backup application 116 on the backup server 104 would receive the filecontents from the source machine 102 of a file to be backed up.Afterwards, in step 302, the backup application 108 can write thereceived file contents to the mount point folder.

The writing of the file to the mount-point folder causes the operatingsystem of the backup server 104 to generate block level write requestsfrom the file system that the backup application 108 has virtualized atthat mount point. The usual file system metadata maintains structuressuch as inodes and superblocks to track what blocks a file occupieswithin a file system. Thus, when a file system write occurs to one ofthe mount points, file names, inodes, and block addresses are allcreated or used to locate the blocks of the “virtual volume” where thatfile is to reside or already resides. However, the block data does notactually get physically written to blocks of that virtual volume;instead it is intercepted below the file system by the backupapplication 108 and processed as described herein.

The block-level data includes blocks that have an address which is anoffset value from the start of their respective virtual volume. Thus,block “8” is the eighth sequential block starting from the beginning ofthe virtual volume. However, as mentioned above, each “virtual volume”is associated with a different contiguous portion of the disk image.Thus, if the second virtual volume, for example, started at block “100”of the disk image, then block “8” in that virtual volume is actuallyblock “108” of the disk image.

Therefore, when the block-level data is intercepted by the backupapplication 108, a determination has been made by the operating systemand file system, in step 306, as to what blocks of the disk image areinvolved in the write request. When a file has never been copied before,then the file system can write the file to any open blocks; however, ifthe file has previously been written to the disk image, then the inodetables and other file system data structures and functions can determinethe blocks occupied by that file (relative to the beginning of thevirtual volume).

In accordance with the principles of the present disclosure, a hashtable of the blocks written to the disk image is maintained by thebackup application 108. For example, a disk image may have 100 blockswith each block size being 4 K bytes. A hash table can be created, andstored separately from the disk image, that is 100 bytes in length. Eachbyte of the hash table represents a hash value of one of the blocks ofthe disk image. In other words, the 45^(th) byte of the hash tableincludes 8-bits that represent a hash value for the 45^(th) block of thedisk image. One of ordinary skill will recognize that different sizehash tables and different hash calculation algorithms can be usedwithout departing from the scope of the present disclosure. The purposeof the hash process is to generate a value that changes whenever anypart of its corresponding disk image block changes. The much-shortersize of the hash value allows it to be tested easier than evaluating allbits of the corresponding data block.

Thus, in step 308, for every block that is to be written to the diskimage (all blocks for a full backup) a hash value is calculated and thehash table is updated. The backup application 108 then, in step 310,writes the blocks to the disk image. As mentioned above, the blockaddress in the disk image takes into account the block number within avirtual volume and the offset value of that virtual volume relative tothe starting block of the disk image.

FIG. 3B illustrates a logical diagram of how further details of how adisk image is constructed in accordance with the principles of thepresent disclosure. For example, a write of “File A” to one of the mountpoints can be performed by an application executing on the server 104.At this stage, the application is writing a file data stream 320. Thiswrite operation results in the operating system of the server 104 togenerate block-level write data 322 which is intercepted by the backupapplication 108. For example, the backup application 108 determines thatblocks 0, 1, 2, 4, 5, and 6 were chosen by the operating system to beused to store “File A”. Thus, the block-level write requests for “FileA” may involve blocks: 0, 1, 2, 4, 5, and 6 which have the respectivevalues: A, B, C, E, F, and G. These block numbers are relative to thefirst block of the virtual volume where “File A” is located. The “FileA” is just used to describe the block write process, but it isn't usedby the backup application 108 here. The backup application 108 focuseson the data blocks, not the file. In a full backup, the backupapplication 108 will write all the blocks to disk image blocks 324. Theaddress of the blocks within the disk image is a combination of bothwhere the virtual volume starts within the disk image and the blockoffset value of the file's data blocks within the virtual volume.

Initially the hash table 326 for the disk image is empty. Once thebackup application 108 determines which of the blocks 322 are to bebacked up in the disk image 324, the hash values for these blocks arecalculated. The hash values are then used to produce an updated hashtable 326. Similar to before, if block “8” of a virtual volume is to bebacked up and that virtual volume starts at block “100” of the diskimage, then hash value “108” of the disk image hash table is updated.

FIG. 3C is a flowchart of an example process for performing anincremental backup to a disk image in accordance with the principles ofthe present disclosure. An incremental backup can generate its own diskimage file separate from the full backup disk image file describedabove. The disk image can also record its parent disk image (the lastincremental backup disk image or the full backup disk image) in itsmetadata. Then they can be used to determine where the data are locatedin the disk image link when performing a restore job. However, the blocknumbers, offsets, and mount points remain consistent between the twodisk image files. When performing an incremental back, the sourcemachine, in steps 340 and 342, determines that “File A” (the examplefile from FIG. 3B) has changed and sends “File A” to the backup server104. In step 344, the backup application 108 writes “File A” to theappropriate mount point which generates block-level write requests atthe operating system. The backup application 108 intercepts theblock-level write requests in step 346 and a respective hash value iscalculated for each block that is included with the block-level writerequests, in step 348. For example, the block-level write requests for“File A” may involve blocks: 0, 1, 2, 4, 5, 6, and 7 (element 360 ofFIG. 3D) which have the respective values: A, B′, C, E, F′, G, and H.

In step 350, the backup application 108 compares each of the calculatedseven hash values to their respective counterpart in the disk image hashtable 328. In this example, the hash values B_(H)′, F_(H)′ are differentfrom B_(H), F_(H) and H_(H) is a new added value, so the backupapplication 108 could determine that of the seven blocks 360 associatedwith “File A”, only blocks 1, 5 and 7 have changed since “File A” waspreviously copied. Thus, in step 352, the backup application 108 writesonly blocks 1, 5, and 7 to the blocks of the incremental backup diskimage file (element 362 of FIG. 3D). Also, in step 352, the backupapplication updates the hash values of entries 1, 5, and 7 of the hashtable 328 to generate a new hash table 364. The other values in the hashtable 328 are not changed and remain the same in the new hash table 364.

Compared to a file-level backup, a backup application in accordance withthe principles of the present disclosure backs up only changed blocks ofa file rather than the entire file. Also, because the backup form isthat of a disk image, it can be used like a volume restore procedurewhich typically uses simpler logic and is faster than other types ofrecovery operations. Compared to a volume-level, or block-level, backupno kernel-level drivers need to be used on a source machine; and becausethe backup appears to be at the file-level on the source machine thedefining of backup policies is easy and flexible.

Referring to FIG. 4, a block diagram of a data processing system isdepicted in accordance with the present disclosure. A data processingsystem 400, such as may be utilized to implement the hardware platform104 or aspects thereof, e.g., as set out in greater detail in FIG.1-FIG. 3D, may comprise a symmetric multiprocessor (SMP) system or otherconfiguration including a plurality of processors 402 connected tosystem bus 404. Alternatively, a single processor 402 may be employed.Also connected to system bus 404 is memory controller/cache 406, whichprovides an interface to local memory 408. An I/O bridge 410 isconnected to the system bus 404 and provides an interface to an I/O bus412. The I/O bus may be utilized to support one or more busses andcorresponding devices 414, such as bus bridges, input output devices(I/O devices), storage, network adapters, etc. Network adapters may alsobe coupled to the system to enable the data processing system to becomecoupled to other data processing systems or remote printers or storagedevices through intervening private or public networks.

Also connected to the I/O bus may be devices such as a graphics adapter416, storage 418 and a computer usable storage medium 420 havingcomputer usable program code embodied thereon. The computer usableprogram code may be executed to execute any aspect of the presentdisclosure, for example, to implement aspect of any of the methods,computer program products and/or system components illustrated in FIG.1-FIG. 3D.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousaspects of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularaspects only and is not intended to be limiting of the disclosure. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of anymeans or step plus function elements in the claims below are intended toinclude any disclosed structure, material, or act for performing thefunction in combination with other claimed elements as specificallyclaimed. The description of the present disclosure has been presentedfor purposes of illustration and description, but is not intended to beexhaustive or limited to the disclosure in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of thedisclosure. The aspects of the disclosure herein were chosen anddescribed in order to best explain the principles of the disclosure andthe practical application, and to enable others of ordinary skill in theart to understand the disclosure with various modifications as aresuited to the particular use contemplated.

1-30. (canceled)
 31. A method, comprising: receiving, by an applicationexecuting on a first computer system, a request from a second computersystem to backup a particular file, wherein the request includes theparticular file; causing, by the application, an operating system of thefirst computer system to generate a set of block-level write requestsbased on the particular file, wherein each of the set of block-levelwrite requests includes data to be written to a respective block of astorage medium accessible to the first computer system; for eachblock-level write request in the set, the application: intercepting thatblock-level write request from the operating system; determining whetherthat block-level write request includes data that is not stored in therespective block associated with that block-level write request; andwriting the data included in that block-level write request to therespective block only in response to the determining indicating thatthat block-level write request includes data that is not stored in therespective block.
 32. The method of claim 31, further comprising:creating, by the application, a disk image on the storage medium,wherein the disk image comprises a plurality of blocks for storing data,and wherein the particular file is written to a set of the plurality ofblocks.
 33. The method of claim 32, further comprising: maintaining, bythe application, a table having a respective entry for each of theplurality of blocks of the disk image, wherein a given entry is operableto store a hash value that is calculated by hashing data stored in ablock corresponding to that given entry.
 34. The method of claim 33,wherein the determining of whether that block-level write requestincludes data that is not stored in the respective block includes:calculating, by the application, a first hash value based on the dataincluded in that block-level write request; and comparing, by theapplication, the first hash value with a second hash value stored in anentry of the table that corresponds to the respective block associatedwith that block-level write request, wherein the first hash value notmatching the second hash value indicates that the data included in thatblock-level write request is not stored in the respective block.
 35. Themethod of claim 33, wherein the determining of whether that block-levelwrite request includes data that is not stored in the respective blockincludes: determining, by the application, whether an entry of the tablethat corresponds to the respective block associated with thatblock-level write request includes a hash value.
 36. The method of claim33, further comprising: for each block-level write request in the set,the application further: calculating a hash value based on the dataincluded in that block-level write request; and storing the calculatedhash value in an entry of the table that corresponds to the respectiveblock associated with that block level write request only in response tothe determining indicating that that block-level write request includesdata that is not stored in the respective block.
 37. The method of claim31, wherein the causing of the operating system to generate the set ofblock-level write requests includes: sending, to the operating system bythe application, a request to write the particular file to a mount pointof a file system created by the application.
 38. A non-transitorycomputer readable medium having program instructions stored thereon thatare capable of causing a computer system to implement an applicationcapable of performing operations comprising: receiving, from anothercomputer system, a request to backup a particular file included in therequest; causing an operating system of the computer system to generatea set of block-level write requests for writing data of the particularfile to a disk image accessible to the computer system, wherein each ofthe set of block-level write requests indicates one or more blocks ofthe disk image and includes data to be written to the one or moreindicated blocks; and for a given block-level write request in the set:intercepting the given block-level write request generated by theoperating system; determining whether the given block-level writerequest includes data that is not stored in the one or more blocksindicated by the given block-level write request; and writing dataincluded in the given block-level write request to the disk image foronly blocks indicated by the given block-level write request that aredetermined to not store data, included in the given block-level writerequest, that is to be written to those blocks.
 39. The medium of claim38, wherein the operations further comprise: maintaining informationthat provides, for each one of the one or more blocks indicated by thegiven block-level write request, an indication of data stored in thatblock.
 40. The medium of claim 39, wherein the determining of whetherthe given block-level write request includes data that is not stored inthe one or more blocks includes: for each one of the one or more blocks:calculating a hash value based on data included in the given block-levelwrite request that corresponds to that block; and comparing the hashvalue and the indication provided in the information that corresponds tothat block.
 41. The medium of claim 39, wherein the operations furthercomprise: updating indications provided in the information for onlythose blocks for which data that is included in the given block-levelwrite request is written to the disk image.
 42. The medium of claim 38,wherein the disk image is associated with one or more volumes of astorage device, and wherein the operations further comprise creating afile system for each one of the one or more volumes.
 43. The medium ofclaim 42, wherein the causing of the operating system to generate theset of block-level write requests includes: performing a write operationto write the particular file to a mount point of a file system createdfor particular one of the one or more volumes.
 44. The medium of claim38, wherein the operations further comprise: receiving, from the othercomputer system, disk information defining a number of blocks of astorage device; and creating the disk image based on the received diskinformation.
 45. A method comprising: receiving, by an applicationexecuting on a computer system, a request to backup data that isincluded in the request, wherein the data included in the requestcomprises a set of portions; causing, by the application, an operatingsystem of the computer system to generate block-level data thatidentifies, for each one of the set of portions, a respective block of adisk image for storing that portion; intercepting, by the application,the block-level data from the operating system; and writing, to the diskimage by the application, only portions in the set that include datathat is not stored in the respective blocks of those portions.
 46. Themethod of claim 45, further comprising: maintaining, by the application,a table that includes, for each block of the disk image, an entry forstoring a value indicative of data stored in that corresponding block.47. The method of claim 46, further comprising: determining, by theapplication, the portions in the set to write to the disk image by: foreach portion in the set: calculating a hash value by hashing thatportion; and comparing the hash value to a value in an entry of thetable that corresponds to the respective block associated with thatportion, wherein the hash value matching the value is indicative thatthe data included in that portion is stored in the respective blockassociated with that portion.
 48. The method of claim 46, furthercomprising: calculating, by the application, a hash value for each oneof the portions in the set that are written to the disk image; andstoring the hash value, for each one of those portions that are writtento the disk image, in an entry of the table that corresponds to therespective block associated with that portion.
 49. The method of claim45, wherein the disk image comprises a set of sections, each of whichcorresponds to a volume, and wherein the method further comprises:creating, by the application, a file system for the corresponding volumeof each one of the set of sections.
 50. The method of claim 49, whereinthe causing of the operating system to generate the block-level dataincludes: requesting, by the application, the operating system to writethe data included in the request to a mount point of the file systemcorresponding to a particular one of the set of sections.